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Abstract 
As a part of their deliverables, working groups of the IETF may 
develop BEEP profiles. During the development process, it is 
desirable to assign a transient identifier to each profile. If the 


profile is subsequently published as an RFC, then a permanent 
identifier is subsequently assigned by the IANA. 
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Introduction 


Each BEEP profile [1] is identified by a URI [2]. The BEEP 
specification uses URIs to identify a BEEP profile both: 


o statically, when a profile is formally defined (RFC 3080’s Section 
5.1); and, 


o dynamically, during channel management (RFC 3080’s Section 2.3.1). 


If the BEEP profile appears on the standards-track [3], then the IANA 
is responsible for assigning the URI associated with the BEEP 
profile. Otherwise, the entity specifying the BEEP profile is free 
to assign a URI under its administration to the profile. 


If a working group of the IETF is developing a BEEP profile, then, 
during the development process, it is desirable to use a transient 
identifier for the profile. Further, it is desirable that the 
transient identifier be associated with the working group. 


This memo defines the practice for making such an assignment. Note 
that this practice does not apply to activities outside of working 
groups -- anyone able to assign a URL is capable of defining a URI 
for the purposes of identifying the BEEP profiles that they develop. 


Practice 


When a working group is formed, the IETF secretariat assigns a brief 
mnemonic prefix to the working group, e.g., "provreg" or "sacred". 


When a working group begins development of a document which specifies 
a BEEP profile, the working group chair assigns a transient 
identifier of the form "http://iana.org/beep/transient/XXX/YYY" where 
"XXX" is the working group’s mnemonic and "YYY" is a unique string. 
Although the resulting URI must conform to the URI syntax, the "yyy" 
portion is otherwise arbitrary. For example, it may contain a sub- 
hierarchy (e.g., "“epp/1.0"). 


For example, 


http://iana.org/beep/transient/provreg/epp/1.0 
http://iana.org/beep/transient/sacred/pdm 


might be assigned by the chairs of the "provreg" and "sacred" working 
groups, respectively. 


Following this, the working group chair completes a BEEP profile 
registration template, and submits this information to the IANA. 
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Note that although the IETF hasn’t established a practice with 
respect to the use of capitalization in URLs employed for namespace 
purposes, the W3C has a lowercase-only policy. Working group chairs 
are encouraged to consider this when making assignments. 


3. Security Considerations 
This document describes an administrative convention and raises no 
additional security considerations. Of course, each BEEP-—based 
protocol has its own set of security considerations, which should be 
described in the relevant specification. 
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Appendix B. IANA Considerations 


The IANA maintains a registry of transient identifiers used for BEEP 
profiles under development in the IETF, using the profile 
registration template defined in Section 5.1 of [1]. 


Note that unlike the registration procedures defined in Appendix B of 
[1], the working group chair (instead of the IESG) is responsible for 
authorizing the registration. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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